从数据科学实施方案中的资源、需求、工具分类、选型、及成本聊开去

数据科学实施方案

首先请读者朋友们注意，虽然数据科学与数据分析有不同的使用场景，但在本系列中我们将两个名词不加区别的混用，也是为了突出分析或洞察是数据科学的核心所在。

了解我们所在组织的具体情况和目标

随着一些组织（包括个人）业务上的发展，对数据科学的重视程度日益增长，但对于具体如何将数据科学应用在业务上，并没有一个统一的答案。这主要是因为对于不同的组织，他们的目标以及可以调动的资源不尽相同。

有的组织，不仅拥有很多数据科学家，还拥有很多程序员，那么他们就有更多的方案进行选择，不管是自研、部分外包、使用商业方案或是进行各种混合都可以，非常的灵活；有的组织，认为数据科学很重要，但并没有人力资源能够投入，这种情况他们有可能会将具体问题外包给第三方，定制解决；还有一些组织，他们的需求很常见、很标准，并不需要太多特别的东西，只需要与其他组织差不多一样即可，这种情况他们可能直接购买商业成熟产品更为合适。所以，当数据科学具体实施时，需要具体了解我们组织的特点，选择实用的方案。

在选择方案之后，我们也应该意识到我们选择方案的局限性。比如我们想实现图像分类这个很标准的功能，那么我们就不应该花费太多时间和精力进行图像收集和模型训练的工作。我们只需要选择一些在这个方面出色的公司，比如 Google、Amazon 或百度等公司，然后再查看他们具体的图像分类 API 的接口，进行编码就可以了。当然有的时候，可能不是那么特别标准的功能，比如识别一些特定的、不在 API 文档中的东西。这种情况我们也许需要一些额外的工作，少量标注图像，然后进行迁移学习就可以了，比如 Google 的 AutoML Vision 就支持这样的工作流程。再比如我们的人员有限，也并不想组织一个数据科学团队，那么我们也许可以选择一个自动化的方案，虽然达不到最优方案，但至少是一个够用，beating the averages(超过平均水平)的方案。

如果想要达到行业最佳性能，那么我们的组织需要更多的投资来组建科学家团队以及工程团队。

所以只有详细了解了我们组织的具体情况和目标，才能选出一套恰当的方案。

数据分析工具分类

当了解了自己组织的资源情况，确定了具体的数据分析目标之后，接下来就是数据分析工具的选型了。选型涉及到的问题非常宽广，从供应商提供什么样的软件，他们是否能够了解客户需求，是否能够根据需求持续提供服务与支持，他们下一步的发展是如何计划的，如何进行数据的迁移和整合，如何进行数据治理与数据资产管理，如何和现有技术架构融合，是否支持混合云和云间环境的数据集成，其他使用这款软件的公司什么样的感受，等等等等。在选型之前，我们先粗略了解下数据分析工具的分类。

根据工具抽象层次进行分类

任何一个理工科专业的同学，肯定都接触过数据分析类的工具，但可能大部分工具（在抽象层次上）都比较底层。比如有的专业甚至需要用 c/c++ 去做一些分析数据，在这种情况下，需要一个人去做一些与数据分析没有直接关系，但却支持着整个分析过程的繁琐工作。

而文科专业的同学，因为专业所限，大部分情况下不会像理工科专业的同学一样，用一些非常底层的工具去做分析。他们在分析时大多会使用一些抽象层次比较高的工具，这些工具在带来便利性的同时，也损失了一部分的灵活性。

以上是在抽象层次角度对工具进行了高、低两类划分。值得强调的是，这里的高、低只是工具抽象层次上的不同，并没有优劣区别。对于不同情况下的问题，需要根据情况进行合理的选择。

根据分析过程进行分类

从整体分析过程角度来看，大致可以分为三类：

• 第一类的重点在于记录，不在于分析，比如 Excel 和数据库都归入此类。也许你能够写一些 VBA 对 Excel 中的表格进行一些基础操作，或是写一些 SQL 语句对数据库中的数据进行统计，这类工具可扩展性总归有限；
• 第二类的重点在于转换、分析，比如 SAS，SPSS，Lingo，Orange，KNIME，Pentaho，Rapidminer，Weka，R，Matlab，Python，Alloma，Spark，Google's dataprep 等工具。甚至连 Linux 中的命令，sed、awk，熟练使用后，都会相当强大。这些工具有一些是开源的，有一些是收费的；有一些是离线使用的，有一些是在线使用的，复杂度也各有差异；
• 第三类的重点在于展示，可视化。近些年流行起来的工具在这一方面都做的不错，比如 Tableau，PowerBI，QlikView 或是一些专门制作 dashboard（可视化面板）的工具等。

这三类并不是完全割裂开的，而是各有重点，互相渗透，而且各类工具发展的方向也是在做好自己本职任务之后，对其他工具的领域攻城略地。

数据分析工具的选型指南

略

数据分析的成本

在选型时，除了功能性的考虑之外，需要特别注意的一点是考虑数据分析工具的成本。数据分析的工具（软件）成本和市场中普通的产品成本并没有太大区别，总成本都是由设计成本，生产成本，维护成本，营销成本四大类组合而成的，各类的占比有所差别而已。

拿一个非软件行业的产品 -- 电视机来举例，有人喜欢买 M 牌电视，有人喜欢买 S 牌电视，花同样的钱，他们买到的产品是不一样的。（以下只是虚无缥缈的举例，并无实际数据支撑）也许 M 牌电视的硬件性能更好，原料成本，生产成本更高。但假如 M 牌电视的故障率要比 S 牌电视的故障率高的话，那么 M 牌电视的维护成本也会高一些；另一方面，如果 S 牌在外观，屏幕，声音系统较M牌电视好，那么 S 牌电视在设计成本上会高一些。而营销成本则取决于产品的定位以及市场，营销人员的具体操作了，略过不提。

软件成本也很类似，对于不同的软件，成本的组成也是不一样的。对于复杂程度不高的（类）一次性软件，比如，软件公司如果要向某某机构兜售只有新闻等简单功能的网站，那么总成本有很大一部分需要分配在营销上，其他方面就可以相对减少；对于一个需求变动比较大的软件，那么设计成本，生产成本和维护成本就要占很高比例，其中软件的内在设计是最最重要的，如果设计的好，那么生产成本和维护成本都可以显著降低，如果设计的的不好，那么，生产成本和维护成本就会急剧上升，而且对于越大的，设计越不好的项目，生产成本和维护成本会上升的更快。

对于用户来说，花了成本（钱或者时间），学习使用了软件，在使用过程中，也许会遇到各式各样的软件问题。软件的问题在表现形式上可以分为两类，一类是 bug -- 指显著表现出来的程序错误；另一类是缺陷，大部分情况下，它是隐藏状态，只有在特定的情况下，缺陷才会被触发，变成 bug。可以说，缺陷是未发现的 bug，或 bug 是已经发现了的缺陷。假如一个软件由三个部分构成，因为设计或编码生产的问题，这三个部分的固有缺陷都是2个，看上去不太多对吗？但实际上，如果缺陷被触发，那么程序表现出来的异常可能有4*4*4-1种组合（对吗？=P），这也是为什么有时会觉得，原来软件都是正常的，但后来只新增了一个模块，怎么一下子出现了这么多莫名其妙的问题的逻辑所在。

也正是因为这种乘数效应，所以程序中大到模块，小到函数，都鼓励写成高内聚，低耦合的方式，并在"尽可能简单，而不过于简单"的总体思路下进行设计。锻炼良好的判断力和品味应该是每一个程序设计者、数据分析者所追求的。

软件行业中的很多活动其实可以理解为，它们都是围绕着降低成本来运行的。比如，敏捷开发是近些年很流行（且被一些管理人员滥用）的概念，它的主导思想是以用户尽量独立的"小需求"为核心，采用迭代，循序渐进的方法进行软件开发，它是把总需求划分成了若干"小需求"，在每个"小需求"中使用迭代开发，及时将产品交付客户体验，紧跟客户真正的需求，通过这种方式来提升开发质量以降低维护成本；还有 TDD，BDD 等开发模式，是在开发成本和维护成本上下功夫；再比如软件文档，命名规范等都是为了减少维护成本而适当增加开发成本，用以达到降低总成本的目的。

当我们需要一款软件，或是分析数据时，成本也是我们重点考虑的内容之一，如果这个任务是一次性使用的，那么应该有一套方案，如果这个任务是要经常做的，或者这个任务会不停的变动内容，那么就需要另外不同的方案。

如果我们在一个任务不停变动（需求在不停变动）的时候选择了一个一次性的解决方案，那么这套解决方案在后期的维护成本可能会非常巨大，甚至导致这个解决方案完全无法使用，需要全部推倒重来。而在整个过程中，除了一些金钱成本之外，浪费了我们最重要的时间成本。What A Sad/Bad Thing(太可惜了)。

数据分析、机器学习在工程上来看，和软件开发并无二致，并且是一种特定类型的软件开发 -- 需求和行动变动的都比较频繁的那种。所以，以上的软件成本理论，完全可以应用在数据分析以及机器学习上，对于个人来说，除去一些微不足道的金钱成本之外，唯一需要考虑的就是自己最宝贵的时间，自己的时间怎么在这些方面分配，是一个需要持续思考和改进的问题。对于我们所在的组织来说，金钱成本、人力成本、整个技术栈是否有良好的后续支持（我们所在组织的技术水平以及技术栈相关的社区环境）等等方面都需要进行综合考虑。

案例：一次聊天

有一次朋友一上来就问我：微软的 PowerBI 和 Oracle hypersion or TM1 有什么区别？她查了一下，说没有看太懂，所以来请教我。

PowerBI 曾经简单试用过，Oracle 家的这个工具我却知之甚少，但那不重要。对于软件区别的问题，只需要打开搜索引擎， 搜索 tool A vs tool B, 或者 tool A tool B 对比 就肯定能够找到答案。如果朋友看了区别之后还是感觉疑惑，那么肯定是他自己真正的问题并不在软件层面。（关于如何问问题请回顾 '01 前言/02 方法论 之 你会问问题吗？'）

朋友在国外做金融模型，所以下面节选的对话中夹杂了一些不中不英的内容，对对话中具体工具不了解完全可以跳着看，不影响理解

Sarah: 我想找的工具需要处理不同系统出来的数据，通过自动做 mapping 或 data cleaning 来生成想要的 report 或 dashboard

指北君: 其实你想一想这个问题，这是一个非常通用（general）的需求，但这个需求不是一个需求，在它里面其实夹杂着很多小需求。 简单来说，你要求的工具，涉及到的子功能比较多：处理不同系统出来的数据，叫做 Data Integration(数据集成), 你这个集成工作是一次性的还是以后会多次重复，是你一个人用的，还是团队的人都要用？ mapping 或 data cleaning (数据清洗)也会有类似的问题，而且又会涉及到 data quality，影响到后续模型的精度。 分析又是 data management or analytics，又会有一大堆可选项。 我只能提供方向，具体还得你看哪个适合你，本地部署还是云端部署、私有云或公有云又是不同的解决方案。如果是特定细分领域的又要看特定细分领域的工具和你想找的工具的结合是否容易，数据流是否通畅。需不需要编程？上手难度怎么样？需不需要扩展性？扩展性怎么样？对于大数据平台的支持情况怎么样？执行效率是否能接受？都需要按照自己的情况具体考量。没有通用的平台，只有适合你的平台，需要自己先搞清楚自己的问题。

各种数据工具

Sarah: 面临主要问题是做一个分析员工效率及成本的 dashboard. 但分析所需的 data source from different systems. 我可以实现用 power BI 把数据导进来形成最后的 dashboard. 但因为 system 之间无 connection, 如何做到时时监控更新我的 dashboard？我不能每次新数据出来，还要重新系统里导出，refresh my financial model

指北君: 对于你这个case，自动化导出流程是最实际的方法。但，你这不是已经通过power bi把各系统连接起来了吗

Sarah: 但是不能时时看更新了的 dashboard. 比如说下个月又要去各系统 export data source, 再导到 power BI 生成新月份的 dashboard 结果。 我说的时时，就是每时每刻由于企业系统数据都在变，随之我的 dashboards 跟着随时变。Power BI 主要是可以 import 比如几个 excel worksheet or word file 进来进行整理。我知道了，各系统可以和 excel 通过写 query 建立联系。我所有 data source 是 excel format 就好

指北君: power bi 可以直接接数据库吧？Excel这一步似乎多余了

Sarah: 真的？ 就是能接就太棒了 接数据库是要专业IT写个程序么

指北君: 如图，power bi是可以直接连数据库的

power bi 连接数据源

你的 excel 是从哪里导出的 谁负责，就问谁，连个数据库很快的，不需要专门写程序

Sarah: 明白了 行，我知道了，谢啦

---

朋友本来以为这个事情可能会比较复杂，结果最后没想到解决方案会这么简单。

有这么一句古老的箴言：

如果你手里有一把锤子，所有东西看上去都像钉子。

当你遇到一个问题时，先别急，先别急着找锤子。先去理解你要解决都真正问题，再根据你的时间、金钱预算去寻找适合的工具，也许一把螺丝刀就够了呢？